A Formal Framework of Virtual Organisations as Agent 

Societies 



We propose a formal framework that supports a model of agent-based Virtual Organisations (VOs) for 
service grids and provides an associated operational model for the creation of VOs. The framework 
is intended to be used for describing different service grid applications based on multiple agents and, 
as a result, it abstracts away from any realisation choices of the service grid application, the agents 
involved to support the applications and their interactions. Within the proposed framework VOs are 
seen as emerging from societies of agents, where agents are abstractly characterised by goals and 
roles they can play within VOs. In turn, VOs are abstractly characterised by the agents participating 
in them with specific roles, as well as the workflow of services and corresponding contracts suitable 
for achieving the goals of the participating agents. We illustrate the proposed framework with an 
earth observation scenario. 

1 Introduction 

The basic definition of Virtual Organisation (VO) is simple enough: organisations and individuals who 
bind themselves dynamically to one another in order to share resources within temporary alliances |[TOll . 
Several issues arise at various levels of abstraction when attempting to describe the alliance, the binding 
between members and the sharing of resources. We focus on an abstract, high-level description of VOs 
and their lifecycle and define a formal model for VOs and their formation that can guide their realisa- 
tion. Like others (e.g. ||4j |8] [TTl) we focus on VOs that can be formed and managed automatically by 
intelligent agents. To support the envisaged automation agents represent organisations and individuals 
by providing and requesting resources/services, by wrapping them or by connecting to their published 
interface. Agents are designed to incorporate the requirements of these organisations and individuals 
and exhibit some human aspects while supporting the decision-making processes automatically. Unlike 
existing work, we abstract away from concrete realisation choices of VOs so that our models can be 
applicable to a range of service grid applications. Instead, the framework focuses on what we believe are 
likely to be the essential elements of VOs and ignore a number of lower-level aspects that are normally 
included in reference models for collaborative networks (see fit). 

Assuming a set of essential elements that are applicable across applications, our representation for the 
operational aspects of VOs relies upon the notion of VO life-cycle, which reflects the orthodox managerial 
and technical views of VOs, as proposed by EJ |9l [161. This lifecycle can be structured in three main 
phases: and the selection of partners, formation, operation, and dissolution. In this paper we focus on 
the formation phase with subphases: (i) initiation, whereby an initiating agent identifies the goals that 
it cannot achieve in isolation and discovers the potential partners who can assist it in achieving those 
goals; and (ii) configuration, involving some form of negotiation, trivial or otherwise, and the selection 
of partners, trimmed down from those discovered, who will constitute the members of the VO once it 
is started. We see a VO abstractly as a tuple consisting of agents participating in the VO, roles they 
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play therein, goals the VO is set to achieve, the workflow of services being provided within the VO, 
and contracts associated with these services, to which agents are meant to conform. We then define the 
formation phase of a VO as a transition system between tuples providing partial approximations of the 
resulting VO. Within our framework and for the purposes of VOs, agents are seen as existing within 
agent societies: we define these abstractly as our starting point. VOs then emerge within societies as a 
result of interactions amongst agents, as determined by the roles they play. 

Throughout the paper we shall exemplify the proposed framework for VOs by showing how it can 
be applied to the following simple but realistic earth obsevation scenario. 

A government official is asked to investigate the detection of an offshore oil spill. As the 
ministry where the official works does not have direct access to earth observation facilities, 
the official typically follows a procedure. The first step of such a procedure is for the official 
to call a number of companies that control satellites which may provide suitable images. 
Satellites may have different orbits, sensors, capabilities and costs, so the official needs to 
discuss with satellite companies in order to select their most appropriate services for the task 
at hand. Satellites have names such as Envisat, ERS-1, and RADARSAT. 

As the satellite output is normally provided in the form of raw images, not immediately 
suitable for the detection of an oil spill, the second step of the procedure involves the official 
calling companies that provide processing services by appropriate software, for example 
for format conversion (into formats such as TIFF, JPEG, etc), reprojection (into different 
coordinate systems), pattern recognition (to detect in the environment objects such as ships 
and buildings or features such as oil spills). After a post-processing image company is 
selected, the output of the satellite is processed by them and the resulting image will allow 
the official to identify the cause of the oil spill. 

We will reinterpret this scenario by assuming that the government official is a user of an agent-oriented 
service grid. In such a grid, services such as oil spill detection and image processing are automatically 
discovered and negotiated by software agents that act on behalf of people and/or organisations. In this 
interpretation, the scenario will result into the formation of a VO that consists of the following parties: 
the ministry official and his agent acting as service requester, the satellite company, the post-processing 
company, and their agents acting as service providers. The agents negotiate over the two requested 
services and orchestrate them into a workflow where the post-processing of the image data requires that 
the image data is created first. To guarantee the properties and delivery of the services provided by 
the satellite company and the post-processing company and to ensure those companies are compensated 
for their efforts, all the parties are involved into signing a contract, which binds parties, in particular 
establishing their roles within the VO and defining a Service Level Agreement (SLA). An SLA specifies 
details of the service provision such as the resolution of images, quality threshold, and time of delivery. 
Once the services are delivered via the execution of the workflow, the high-level goal of the user is 
satisfied and the VO is dissolved. 

The paper is organised as follows. Section [2] presents the formahsation of the required abstractions, 
namely: agents, their roles and social norms specified as interaction protocols in an agent society, the 
services/resources available in that society, how these services can be combined in workflows, and how 
interactions in these workflows can be regulated by agreed contracts. These components will become the 
constituents of the VOs and will be produced by a VO's formation phase. This phase is defined as a state 
transition system that will be formalised in section [3] Finally, in section |4] we summarise our work and 
we outline our plans for the future. 
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2 Agent Societies 

For the purposes of VOs, agents "representing" services can be seen as existing within a society (of 
agents). VOs emerge as a result of interactions amongst the agents in this society. In other words, the 
agent society can be seen as the breeding environment [5] for VOs. We will assume that an agent society 
exists prior to decisions and interactions leading to VOs. However, typically this society is intended to be 
"virtual", in that it is the implicit result of the existence of agents and services within an agent-enabled 
grid/service-oriented architecture. 

An agent society is characterised by roles that agents can adopt, services available to and controlled 
by agents in the society, possible combinations of these services within workflows, and possible con- 
tracts between agents. Formally, Agent Society = {Agents, Services, Roles,Workf lows, Contracts). The 
elements of the AgentSociety can be described as follows. 

• Agents is a (finite) set of agents, {Ai, . . . ,A„}, with n >2; each agent is equipped with a set of 
individual goals, an evaluation mechanism, and a set of roles it can cover (see section [23]). 



Services is a (non-empty and finite) set of services represented by agents (see section 2.1 1. 



• Roles is a (non-empty and finite) set of roles that agents can play within the society as well as the 
VOs, once they have been created. We require that there are roles for request er{s) and provider{s) 
in Roles, for all s € Services; roles are associated with interaction protocols (see section [2!2]). 



• Workflows is a (non-empty) set of possible combinations of services in Services (see section 2.4 1 



Contracts is a (non-empty) set of possible combinations of agents (in Agents), roles (in Roles), 



and workflows (in Workflows) as terms in a contract (see section 2.5 1 



Note that, in addition to roles for requester and provider of all available services in the society. Roles 
may also include roles for a broker that provides information on how to obtain or use some services, an 
arbitrator for making sure that interactions for services are suitable regulated, and so on. Finally, note 
that there are no goals of the agent society itself, and goals exist within agents only. However, VOs are 
goal-oriented: we will see, in section[3} that the goals of VOs originate from those of individual agents. 

The components of an agent society will be defined using several abstract underlying languages. 
Here we single out these languages. We adopt the following conventions: variables start with capital 
letters; constants start with lower-case letters or numbers; '_' stands for the anonymous variable. 

We use a set Alas of agent identifiers, that serve as unique "names" to address agents in the society, 
e.g. to support communication. An example is satERSlAg, representing the satellite ERS-1. 

We use a set RIas of role labels for the definition of Roles. We require that requester{s) and 
provider{s) belong to RIas, for all s G Services. 

We use contracts identifiers, Clas, univocally identifying and distinguishing contracts in Contracts. 

We will assume some given, shared ontology Oas, which for simplicity we think of as a set of atomic 
and ground propositions|^ Oas will include (i) (an abstract representation of) all services in Services, 
(ii) generic infrastructure knowledge, e.g. for querying registries holding information about agents and 
the services they provide. An example of the latter may be provides{X ,satlmage{in,out)) instantiat- 
ing X to satERSlAg, representing that the agent named satERSlAg represents a provider of service 
sat Image {in, out) G Services. 



' In general, Oas may need to contain hierarchical concepts, for example a "generic service" may be defined as either a 
"satellite service" or a "processing service". 
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We will see that VOs emerge in an agent society by communicative interaction amongst its members. 
As usual, communicating agents will share a communication language that will act as a "lingua franca" 
amongst agents. We thus assume as given a language ACLas of locutions. As conventional, locutions 
consist of a performative and a content. Examples of locutions in ACLas may be request {s) and accept (s), 
where s G Services is the content. 

Each individual agent is equipped with an internal language to express its knowledge/beliefs and 
goals. Since the goals of VOs are derived from the individual agents' goals, we need to assume that the 
agents share at least a fragment of their internal languages. This fragment can be also used to express, 
e.g., conditions in protocol clauses (see section 2.2 1. We will refer to this shared fragment of all agents' 
internal lane uages as Las- require that the sentence true is contained in this language, as well as 
sentences built using the usual connectives A and We assume that this language is propositional. 
Examples of sentences in Las may be toBuy{satImage{in,out)). Sentences are meant to be evaluated 
using the agents' internal evaluation mechanisms (see section [23] ). 

Note that there are no eligibility conditions to choose which agents enter the society, as we assume 
an open setting where agents can freely circulate. In this context, VOs provide a mechanism for defining 
which agents can be suitably put together to help solving each others' goals. 



2.1 Services 

Concrete services, that can be executed by their providers, are described using sentences in Oas- Exam- 
ples of concrete services are satImage{in,out) with in and out representing the inputs and outputs for 
the service (e.g. in may be [38.0, —9.4, 1000, 500, 5, opf/caZ, 3] and out may be result s.data)^and some 
service for detecting oil-spills detectOilSpills{[a,5],b^ 

In order to accommodate negotiation for the provision of (concrete) services during the formation of 
VOs, it is useful that agents are able to talk about partially uninstantiated and abstract services, before 
they commit to any concrete instantiation (actually, it may happen that this instantiation can only be 
provided at the time of execution of the services). For example, an agent may require, for some given 
a, detectOilSpill{[a,T],B), where the threshold T and the output processed data image B are as yet 
unspecified (T may be associated with constraints, e.g. T > 5). 

In summary, we adopt the following description of services: 

serviceName{In,Out) : uninstantiated service {abstract service); 

serviceName{in,Out) : partially instantiated service; 

serviceName{In,out) : partially instantiated service; 

serviceName{in,out) : fully instantiated service (concrete service); 

serviceName = predicate , with serviceName{i,o) G Oas, 

for constants or lists of constants i,o; 

in, out = constants or lists of constants; 

In, Out = variables or lists of variables. 



^Here, 38.0 and -9.4 are the latitude and longitute coordinates of the area to be scanned, 1000 is the resolution of the image 
in metres, 500 is the km^ area to be scanned, 5 is the frequency in hours for the area to be scanned, optical is the type of sensor 
to be used, 3 is the wave frequency to be used in the scan, results.data is the name of the file produced by Envisat. 

^ Here, a represents the input raw satellite data, 5 is the acceptable threshold for false positives and b is the output processed 
data image, as computed by the provider of detectOilSpill. Note that algorithms for detecting oil spills may occasionally give 
false positives, namely indicate that there is an oil spill at some location where in reality no oil spill is present there. The lower 
the acceptable false positive threshold requested from a service, the more expensive the service. 
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The serviceName can be seen as the "type" of service being provided by serviceName{in,out). We 
will often refer to an abstract service serviceName{In,Out) simply as serviceName. Also, an abstract 
or partially instantiated service can be seen logically as representing a disjunction of concrete services 
(one for each possible instantiation). We could thus see the process of negotiating an instantiation of 
an abstract or partially instantiated service as the process of negotiating a concrete service in a set of 
alternatives (the disjuncts). 

For our scenario, we need four types of services, namely satlmage and three processing services 
(with serviceName one of formatConversion, reprojection and detect Oil Spill). We have already seen 
examples of concrete services of type satlmage and detectOilSpill. 



2.2 Roles and Protocols 

A role is defined as a tuple {rid, PC) where rid G RIas is the label of the role, and PC is a Protocol Clause, 
understood in this paper as a (non-empty and finite) set of Operations defined as follows: 

Operation = \if[send{m,i,rid')\<^ (send operation) 

I \lf[receive{m,i,rid')]^ (receive operation) 

l/A G LasUOas (precondition) 

^ G Las (postcondition) 

m G AC Las (locution) 

i G Alas (unique identifier of agent) 

rid' G RIas (role, label) 

Intuitively, each operation has three parts: a locution m in ACLas, an identifier / in Alas of the com- 
municative partner (i.e. the intended recipient or the actual sender of message m, respectively for send 
and receive), and the identifier rid' of the role that the agent / is intended to be playing when receiving 
or sending the message (respectively for send and receive). An agent can send or receive the locution 
(according to what the operation specifies) if and only if the evaluation mechanism of the agent evaluates 
the precondition i//^ to true. Once the message is sent or received, the postcondition will automatically 
hold (namely the evaluation mechanism of the agent will evaluate this condition positively after the mes- 
sage is sent or received, until further changes). Moreover, when an agent /' playing some role {rid, PC) 
sends a locution send{m,i,rid') to some other agent /, / receives the message from /' indicating that /' 
sent it while playing role rid: receive{m,i' ,rid). This message will be "processed" by / using the role 
with identifier rid' . 

We could adopt other formalisms for communication, e.g. non-determinisitc finite-state automata. 
The reason we have chosen protocol clauses is that this formalism is an abstraction of several existing 
formalisms for modelling inter-agent communication, e.g. LCC 1 13] and dialogue constraints [TT]. 

To illustrate roles, consider a simple example where an agent playing the role of requester (of some 
service S) sends a request to an agent it believes to be a provider of S, and requiring it to be playing 
the role of provider of S. The provider agent replies with accept or refuse depending on whether it is 
indeed a provider of that service S (and it wants to sell that service) or not (respectively). 

( requester(S), { 

toBuy(S) A provides(Ag,S) [send(request(S), Ag, provider(S))] requested(S,Ag), 
requested(S,Ag) [receive(accept, Ag, provider(S))] bought(S), 
requested(S,Ag) [receive(refuse, Ag, provider(S))] true 

} 

) 
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{pwvider(S),{ 

true [ receive(request(S), Ag, requester(S)) ] requestedBy(Ag,S), 
requestedBy(Ag,S)A toSell(S) [ send(accept, Ag, requester(S))] sold(S), 
requestedBy(Ag,S)A -> toSell(S) [send(refuse, Ag, requester(S))] true 

} 

) 

In the two protocol clause schemata above variables S and Ag are used instead of concrete values. These 
variables are implicitly universally quantified over the appropriate languages. 

A protocol clause for a role defines the communicative actions for any agent adopting the role. How- 
ever, protocol clauses typically relate to other protocol clauses and give a global picture of the interaction 
amongst agents and roles. For the earlier example, the two roles, requester{S) and provider{S), are re- 
lated to one another to form a simple negotiation protocol. Intuitively, a protocol is a (non-empty and 
finite) set of protocol clauses for roles in Roles that are "related" to one another, possibly indirectly. 

With an abuse of notation, we will often refer to a role simply by its identifier and will use the 
identifier to stand for the corresponding protocol clauses. Moreover, when an agent needs to play the 
role of requester for any service, we use requester to stand for request er{s) for any service s G Services. 
Finally, we use provider {serviceName) to indicate that a service provider can provide all instances of 
an abstract service serviceName{In. Out) or when we are interested in the provision of some instance of 
this service without specifying which one. 

2.3 Agents 

For the purposes of VOs, an agent can be seen abstractly as a tuple (/,/?, G) where / G Algs is the unique 
identifier for the agent; R C Roles is a (non-empty) set of roles that the agent can play within the society; 
G C Las is a (non-empty) set of goals of the agent. 

An agent is also equipped with an evaluation mechanism for determining whether (i) preconditions 
in roles are satisfied, (ii) goals are fulfilled by the agent in isolation. This mechanism is affected by 
the execution of protocols in that postconditions of protocol clauses are taken into account by this eval- 
uation mechanism (they are satisfied after the protocol clause is executed, until overwritten by further 
postconditions). We do not include this evaluation mechanism within the representation of an agent in a 
society as this mechanism is private to agents and different agents may adopt different such mechanisms 
in general. 

Roles and goals of an agent (/,/?, G) are inter-related as follows: 

(a) Vr G /?, 3g G G which "enables" i to adopt r, namely the need to fulfil g is a precondition for one 
of the protocol clauses in r; 

(b) Vg G G, 3r G /? such that playing the role r gives i a "chance of fulfilhng" g namely one of the 
protocol clauses in r admits the fulfilment of g as one of its postconditions. 

As an example, consider the earlier protocol clause for the role request er{S) where toBuy(S) corresponds 
to a goal and bought(S) corresponds to the goal being fulfilled. Example agents for our scenario are 

{clientAg, {requester}, {toBuy(someI),toBuy{someD)}) 

{satERSlAg, {requester{detectOilSpill) , provider{satImage)} , {toSell{someI)}) 
{detectAg, {provider{detectOilSpill)} , {toSell{someD)}) 

where somel is of the form satlmage{in,0ut) and someD is of the form detectOilSpill{[Out ,t],Out') 
for some in and t (as discussed earlier). Here, the agent identified by clientAg represents the govern- 
ment ministry and can only play the requester role (for any service), the agent identified by satERSlAg 
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represents the ERS-1 satellite and can play both the requester role for detectOilSpill services and the 
provider role for satlmage services, and the agent identified by detectAg can play only the provider 
role for detectOilSpill services. The agents' goals allow them to engage in interactions following the 
protocols for the roles they are equipped with (see the simple protocol clauses of section [2!2i. 



2.4 Workflows 

We see workflows simply as (non-empty) sets of service^ possibly annotated with "constraints", that 
are sentences in Las- Services may be abstract, partially instantiated or concrete, as in section 2.1 As an 
example, consider the annotated workflow (consisting of a single partially instantiated service) 

{satImage{[3S.O, -9.4, Res, 500, 5, ST], Out)} [j {Res G [900, 1100], 5r G {radar, optical}} 

where the resolution Res and sensor type ST arguments are constrained within the annotation. 

We require that the constraints annotating workflows are satisfiable in Las- Annotations only make 
sense for workflows with at least one partially instantiated or abstract service. They are intended to 
restrict the possible instantiations of the services in the workflow. Typically, as in the example above, 
they pose restrictions on the variables occurring in the services of the workflow. 

We will adopt the following terminology: an abstract workflow is a workflow with at least one 
abstract or partially instantiated service (with or without annotations); a concrete workflow is a workflow 
consisting solely of concrete services (without annotations). Also, a concrete workflow may or may 
not be executable, and that, prior to execution of a workflow, may need to be appropriately set up. In 
this paper, we focus on the formation phase of VOs and ignore execution issues that may occur in the 
operation phase. 



2.5 Contracts 

Inspired by web service contract standards Q, we define a contract as {Cid, Context ,SDT,GT) where 

• Cid G Clas is a unique identifier for the contract; 

• Context indicates all agents bound by the contract (the "contracted parties") and their role in the 
contract, formally seen as a set of pairs of the form {Agentid ,AgentRole) such that {AgentId,R, _) G 
Agents and AgentRole C R; 

• SDT, the Service Description Terms, is a workflow, consisting of services being contracted; 

• GT, the Guarantee Terms, is a (possibly empty) set of sentences in Las that define the assurances 
with regards to the services described in SDT- 

The GT component of a contract may also include rewards/penalties for the contracted parties and refer 
to roles (and protocols) to be used by agents in the case of exceptions. For example, if blame for failure 
is disputed, there may be a clause in GT defining a protocol for arbitration. 

By definition of Context, we require that the contracted parties play, within the contract, some of 
the roles they are equipped with. We require that there are at least two different agents involved in any 
contract, and that there is at least one agent playing the role of requester[s) and at least one agent playing 
the role of provider {s) for some service s, namely: 

• 3{id\,role\), {id2,role2) G Context such that id\ ^ id2, and requester's) G rolel, provider's) G 
rolel- 

^More generally, workflows can be compositions, e.g. by sequencing or parallel execution, of services. 
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We exclude the possibility that the same agent may be a provider and a requester for the same service: 

• ^{id,role) G Context such that, for some s £ Services, {request er{s), provider {s)} C role. 
We require that for all the services in SDT there exists an agent in Context providing that service: 

• Vi' G SDT, 3(id,role) G Context such that role = provider{s). 

A simple example of a contract is: 

( contractX, 

{{clientAg,{requester(formatConversion)}), (procF, { provider(formatConversion)})}, 
{formatConversion( [image.jpeg, jpegTOgif], imageGIF.gif)}, 

{dueBy(ImageGIF. gif, MOOhrs, 12.4. 09 ), priceReduced(ImageGIF,1400hrs, 1 2.4. 09, reduction(0. 5))} 

) 

The above contract, identified as contractX, is between clientAg and procF for the delivery of (an 
instance of) the service f ormatConversion, for converting the file image.jpeg using the operation called 
jpegTOgif. The service has a due delivery date specified using the dueBy predicate. The clause on 
priceReduced specifies that the price charged will be halved if the provider fails to deliver on time. 



2.6 From Agents and Services to the Agent Society 



Given Agents as in section 2.3 and Services as in section [271] an agent society "emerges" with: 

• Roles = [j,i 

.R,G)eAgents^ ('^^c possiblc rolcs are all roles that agents within the society can play); 

• the concrete workflows in Workflows are all possible (non-empty) sets of services, namely (2^^"'"^'^'* - 
0) C Workflows, while the remaining elements of Workflows are abstract, possibly annotated 
"versions" of these concrete workflows; 

• Contracts is built solely from elements of Workflows, Roles and Agents. 

We require also that each service is "represented" by an agent within the society, in other words the 
possible services in the society correspond to all services the agents can provide: 

• ys £ Services, 3{provider{s), -) £ Roles 

However, it may be the case that several alternative protocols exist in the society for the same role, 
namely: {rid, PC) and {rid, PC') both belong to Roles for PC / PC'. The creation of a VO will need to 
address the choice of protocols being used for negotiation of workflows and contracts. 



3 The VO Formation Phase 

VOs can be defined as tuples < A^,o,Gvo,Rvo,Wf.o,Convo > whose components can be described as 
follows. 

• Ayo C Agents* with Agents* = {{i,R' ,G')\{i,R,G) G Agents and R' C /?, G' C G}. A,.,, contains at 
least two agents and exactly one agent in Ayo is referred to as the initiating agent, which is denoted 
ago- 

• Gvo is a set of goals for the agents in A,,o, which contains at least a goal of the initiating agent: 

Gvo Q [J(i,R,G)eAgentsG and GoHGyo / ©, where {ago,Ro,Go) £ Agents. 
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• Ryo is a set of roles to be played by the participating agents, where /?vo ^ Roles. 

• Wfvo ^ Workflows is the workflow of services currently agreed amongst the agents in Am- 

• Corivo ^ Contracts is a set of contracts between the agents in A^o- 

Agents* represents the set of all possible "full" or "partial" specifications of agents, corresponding to 
concrete choices of roles agents may play and goals they may focus on within a specific VO. A^o describes 
the (partial specifications of) agents involved in the VO, as providers or requestors of services, or in 
whichever other roles, as indicated by Ry.g. A^j only describes the agents insofar as their involvement 
in the VO is concerned (and thus possibly omitting some of their goals and roles, not relevant to the 
VO). The Wfya and Con^o components determine the behaviour of the VO and its members during 
the execution and dissolution phases of VOs. The Gvo and Vvo components are related to the the A^o 
component in that Gyo = U(/,fi.G)GA„„ G and R,,,, = U(«go,Ko,Go)eA„„ 

In our model, a VO is instantiated during the formation phase, through interactions amongst the 
agents composing the VO. These interactions can be understood in terms of several operations progres- 
sively refining "partial" representations of VOs. These operations are defined as transitions, as outlined 
below. In the remainder, lds{A) refers to all identifiers of (partial specifications of) agents in the set A. 



3.1 Goal Identification 

The identify goals transition results in the additions of the initiating agent ago and (some of) its goals 
into the partial VO tuple. These are goals that the agent cannot achieve on its own. Given 

< 0,0,0,0,0 > ''""'fy^""\ < a™v,g™y,0,0,0 >, 

then 

• Mnit = {{agid,^,Ginit)} for some {ago,Ro,Go) G Agents such that some goals G'q C Gq cannot be 
fulfilled by ago in isolation; 

• Ginit = G'q. 



Here, goal fulfilment is determined using the evaluation mechanism of agent ago (see section 2.3 1. Note 
that no role is yet identified for ago- this will be done in transition establish roles (see section 3.4 1. 

In order to ground this transition to our scenario, we assume that an agent clientAg is informed by 
its user that a possible oil spill has been reported by a passing vessel. The user provides the following 
information to the agent: latitude, longitude, acceptable false positive threshold and scan area. Given 
the user's parameters the agent initiates the VO formation process by first identifying its goals. The 
parameters correspond to high-level goals, that will later be decomposed into specific workflows. In the 
example, the high-level goal detectPossibleOilspill{3S.O, —9.4,500,5) given by the user is to detect an 
oceanic oil spill off the Portuguese coast at a latitude and longitude of 38.0 and -9.4 with an acceptable 
false positive threshold of 5% for the surrounding 500 square kilometres. The agent may decide that to 
satisfy this high-level goal it needs two services: 



gi = toBuy{satImage{[3S.O,— 9.4, _,500, radar, _], _)), and 
g2 = toBuy{oilSpillDetect{[_, _,5\, -)) 

where the sensor-type for the satellite providing the image must be radar, because of the required 
resolution and weather conditions, and once this image data is obtained a service is needed to pro- 
vide the actual identification of the oil spills on the images. In summary, identify goals will compute 
Ainit = {{clientAg,(d, Ginit)} and G™, = {gi,g2}- 
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Note that in our model goals of VOs emerge from goals of agents. Once the goals of VOs have been 
identified, they will dictate the behaviour of agents during the operation of VOs. 

3.2 Partner Discovery 

The discover partners transition results in the addition of a number of agents to the set of agents in the 
current partial VO (after identify goals). Whether by traditional means such as a yellow page registry 
or through 'friend of a friend' discovery utilising the multiagent system, the VO tuple is transformed 
to include potential partners that the initiating agent believes will help it reach its goals, notably by 
providing suitable services. Given 

A ^ n. n. n. discovcv partners ^ ^ n. n. n. 
< Ainu , GinU , 0, 0, > > < Apot , Ginit , 0, 0, >, 

then Apoj =Ainit \JAqueryresult, "^^^^^ ^queryresult includcs those potential partners such that 

• \ueryresult ^ Agents* -Ainu and each element in Aqueryresult is of the form { j, 0, 0) ; 

• each agent inAqueryresuit is a provider of one of the services in Ginu namely, for each / G Ids{Aqueryresult)^ 
if {i,R,G) G Agents then 3s such that toBuy{s) G Gmu such that {provider{s),PC) G R. 

In our example, client Ag finds that two satellite image providers advertise the services it is interested 
in. Both agents satERSlag and radSatAg represent a radar-capable polar satellite with orbits amenable 
to the area of interest. Moreover, there is one agent, procOSAg, who can provide the type of image 
processing in which client Ag is interested. After this transition is completed, 

Aqueryresult = {{satERS\ag,Qi,il)) , {radSatAg,id,id) , {procOSAg, tb,^)}. 

3.3 Partner Selection 

The set of potential partners discovered by ago may include unreliable or untrustworthy ones. The select 
partners transition allows the agent to prune the results of the discover partners transition. We do not 
provide a detailed specification of the pruning mechanism needed to support this stage as this is largely 
dependent on mechanisms for assessing trustworthiness and reliability. Several such mechanisms exist 
in the literature. Any could be used here. 
Generally, given 



A ^ n. n. n. select partners , _ n. n. n. 
< Apot, Ginit, Q>,^,^ > > <Apre, Ginit, <l),<d,<d >, 



then 



• Apre — ApQfi 

• ago e Ids{Apre); 

• for each s such that toBuy{s) G Ginit there exists 

/ G Ids{Apre) such that 
if {i,R,G) G Agents then 
3{provider{s),PC) £ R. 

In the example, after the select partners transition is completed: 

Apre = { {client Ag, 0, G,„,f) , {satERSlag, <b,(b), {procOSag, 0,0)}. 
Note that, in general, several providers of the same service may still be in Apre after the pruning. 
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3.4 Establish Roles 

Before the agents are able to negotiate workflows and contracts, the roles they will be playing in the 
negotiation need to be established. These roles (with their protocols) are the social norms used for 
forming the VO. Establishing these roles also amounts to establishing protocols for them (as our roles 
include protocols). Roles include requester and provider roles, but may also include other roles (e.g. that 
of arbitrator, or contract-negotiator if agents other than provider and requester agents may be needed to 
support the contract negotiation stage of VO formation). For simplicity, we assume that these roles are 
decided by the initiating agent, and that, given 

A ^ n. n n establish roles . „ „ n. n. 

<Apre,Ginit,<d,Q>,Q> > > < Aroles,Gi„it,Rvo,<l>,® >, 

then 

• Ids{Apre) Ids(AroIes); 

• Aroles =A*p^^UArest, whcrC 

- A*p^e = U(i,0,G>eA^„{(j>''?i>G,)} for some /?,s such that C/?? andG,- C G* where {i,R*i,G*) G 
Agents; 

- ^rest Q Agents* (where Arejt may be empty); 

~ ^rest ^■^*pre ~ ®' 

• Rvo = U{/,R,._)GA,,,„{^/}; 

• for each s such that toBuy{s) G Ginu, there exists exactly one {provider (s), PC provider(s)) and exactly 
one {requester{s),PCrequester{s)) vaRyo', 

• for every (ri,PCri) and {r2,PCr2) in Rvo, if n = r2 then PC^ = PCr2, namely there is exactly one 
role for each role identifier in /?vo- 

Note that we do not impose that ago plays the role of requester of all the services in the workflow it 
wants to instantiate: indeed, in general it may be possible that ago delegates the task of requesting some 
or all services to some other agent. In particular, it may be the case that {ago,®,Ginit) belongs to Aroies- 
Also, we allow for the same agent to play several roles in a VO (namely, {i,Ri,Gi) may belong to Aroies 
with Ri containing more than one role). 

In our running example, once the establish roles stage is completed: 

^roles = { {clientAg,{{requester{satImage{[3S.O,— 9.4, _,500, radar, _], _)),PCi) , 
{requester{oilSpillDetect ( [_, 5] , _) ) , PC2)} , Ginu) , 
{satERS\ag,{{provider{satImage{[3S.O, —9.4, _, 500, _, radar, _], _)),PC3)},0) 
{procOSag, {{provider {oilSpillDetect{[-, _,5], _)),PC4)},0)} 

Rvo = { {requester{toBuy{satImage{[3S.O,— 9.4, _,500, radar, _], _))),PCi), 
{requester{toBuy{oilSpillDetect{[-, _,5], _))),PC2), 
{provider{toBuy(satImage{[3S.O, —9.4, _,500, _, radar, _],_))), PCs), 
{provider{toBuy{oilSpillDetect{\-, _,5], _))),PC4)} 

Here, the PC, are protocol clauses that the agents commit to follow during the negotiation of workflows. 
In this specific example, no role/protocol is specified for the agree contract transition. Note that other 
agents may be brought into AroUs at this stage to play these new roles. 
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3.5 Negotiation 

The negotiation activities in the VO formation amount to 1) agreeing a concrete workflow (agree Wf) 
and 2) agreeing a set of contracts amongst agents contributing to the workflow, by providing services 
in it, and the initiating agents (stage agree contract). Both transitions make use of roles (and protocols) 
identified at the establish roles transition: communicating by following these protocols agents agree on 
the provision of services and contracts. Negotiation may result in additional goals to be added, as goals 
of agents providing services. The agree contract transition may cause no changes in the partial VO tuple, 
if no suitable roles have been computed by the establish roles transition. For lack of space we will only 
describe the agree Wf transition. 

In order for the computed VO to be meaningful, it needs to compute a workflow that is concrete 
or partially instantiated, but can be fully instantiated when the workflow is executed. This workflow 
instantiates the abstract workflow corresponding to the toBuy goals in Ginu. This instantiation may be 
obtained after several negotiations, each following the protocols of the roles identified after the establish 
roles transition, each resulting in a service becoming instantiated. After each instantiation, the initiating 
agent puts those instantiated services into the workflow component of the VO tuple. 

Generally, given 

then 

• Ids{Ayo) O Ids{Aroles); 

• ago £lds(Ayo); 

• for each s such that toBuy{s) G Gmit there exists exactly one agent / G Ids{A^,o) such that (/,/?,-, G,) E 
Ayo and provider{s) € and a successful dialogue between ago and this agent / with ago playing 
the role of request er{s) and / playing the role of provider{s) ; 

• for each {i,Rj,Gi) GAvo,if {i,R*,G*) G Aro/e* then /?* =/?,• (namely roles cannot be changed at this 
stage); 

Gi 5 G* (namely goals can only be added at this stage); 

if (/,/?**, G-*) G Agents then G,- C G** (namely all goals are chosen from the pool of goals of the 
agent); 

• Gi„it Q Gvo\ 

• Gvo = U(,-,r,,g,)ga,,„<^(; 

• W^/i'o is the result of instantiating Wf by the given sequence of successful dialogues, as dictated 
by Gvo', the providers of the services are given by Ayo. 

Intuitively, agents may decide to add goals at this stage to avoid agreements to provide a service 
which could prevent the fulfillment of some of their goals. We impose that the initiating agent is not 
allowed to change the workflow. However, it can add constraints or services to it, as soon as no new 
role is required by this addition. For example, this would be needed and useful to support shimming of 
services. Goals of provider agents may render this shimming necessary (e.g. because a service provider 
does not want to interface to another service provider). 

^Informally, shimming is the introduction of a service into a workflow to ensure that the output of a preceding service 
matches the type required by the input of the subsequent service. 
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Another aspect of this formulation is that one single provider per service is required. These providers 
will need to be selected amongst all agents that have successfully completed a dialogue with ago. We do 
not impose any constraints on how this choice is performed: the given protocols may typically dictate 
this. 

4 Conclusions 

We have described a formalisation for VOs in grid and service-oriented architectures, formed from agent 
societies, using a realistic scenario for illustration throughout. This formalisation is abstract and inde- 
pendent of any realisation choices (in terms of agent architectures, communication platform etc). It can 
guide the development of (agent-based) VOs, in that it identifies essential components (such as several 
underlying languages for services, identifiers, communication, as well as protocol-based roles for nego- 
tiation of services and contracts). We have experimented with some of the interactions presented here 
for the earth observation scenario Q with emphasis on the coordination patterns agents should follow 
when creating a VO fTSl]. 

Our emphasis on the use of protocols to support VOs is influenced by flO]. The CONOISE-G ifTTI 
project presented an agent-based model for VOs on the grid, but focused on the challenging task of 
engineering a working system and thus making concrete reaUsation choices (e.g. agents use a constraint 
satisfaction algorithm for decision-making). We have taken a more abstract view of agents, agent society 
and VOs, to ensure that the definitions can be ported to any other agent-enabled grid systems to support 
VOs in general. Papers such as [4J speculate on the consequences of introducing software agents as a 
means to alleviate the burden on human decision-making. We have a similar focus in that we see an 
opportunity in the use of the multiagent paradigm for automating parts of VOs. There are a few papers 
that have formalised aspects of agent-enabled VOs, for example (lT\ look at voting protocols for VOs 
while [17] focuses on the representation of contracts in VOs based on a specific commitment-based 
approach for them. We have taken a more exhaustive view by considering all components of agent- 
enabled VOs but more abstractly. 

There is also existing work applying agent societies and electronic institutions for VOs [15]. There 
are a number of differences of this work from ours as follows. First, our emphasis is one the formal- 
isation of a VO in terms of its components and the VO transitions, not on the details of the regulation 
of the participating agents and their behaviour. Secondly, we abstract away from methodological is- 
sues. Thirdly, we do not require a classification of the goals of agents and a focus on the capabilities 
of individual agents. The regulation of VOs and Electronic Institutions with emphasis on norms is also 
discussed in ||6l, where like here the focus is on agreed contracts about the provision of institutional 
services. However, we abstract away from the monitoring of VO activities and the evaluation of norms. 

As future work, it will be important to further validate the proposed model with further examples, e.g. 
in e-business and pharma settings, as well as formally verifying that the VO formation model provided 
results in "coherent" VOs, namely VOs where all agents involved can fulfil their relevant goals as a result 
of the participation in the VO, given that the VO is executed as agreed. 
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